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Integration Plan for PRISMS, DP3D, and Software Staff 


David W. Sieg 
Omnibus Computer Graphics Inc. 


The recent acquisition of Digital Productions by Omnibus 
Computer Graphics raises some critical issues: 


= What capabilities are offered in the DP technology? 
= How can Omnibus best use this technology? 


- How does the i o of this HEIRDD affect work 
in progress on PRISMS? 


- How should the two systems be integrated? 

= How should the two software staffs be integrated”? 

- What are the ramifications of this integration”? 

This report addresses these issues, recommends a plan for 
the integration of the two systems, and the most cost effec- 


tive use of the systems, and attempts to forecast the impact 
of the plan on the various divisions within the company. 


Copyright (c) Omnibus Research and 
14 Aug 1986 Computer Development 
Version 1 Graphics Inc. Technical Reports 


DP3D/PRISMS Integration Page 1 


Plan Summary 
The proposed plan can be summarized as follows. Supporting 
material can be found in the report sections below. 


Staff Organization 
Except for minor chain-of-command changes, continue support- 


ing both the DP software staff and the PRISMS software staff 
in established directions. This is important for stability 
in each division, as well as to meet existing committments. 


DE3D EYN DID 
Employ for high complexity or fast turn-around jobs; prepare 
jobs with existing DP3D front-end. 


PRISMS _. 
Employ for lower complexity or special projects such as Cap- 
tain Power. 


Interface Programs 
Develop some guick and dirty interfaces between PRISMS and 


DP3D to allow for data interchange. 


NOTE: This will not permit jobs to be completely prepared at 
other sites for final rendering on the Cray. 


New Workstation 

Begin planning and development of the ideal workstation for 
Omnibus” goals. Such a system does not currently exist. 
This project will provide a natural bridge between the two 
systems and get the two software staffs working as a team. 
The result (in approximately 18-24 months) will be a high- 
performance workstation which can be used anywhere in the 
world to prepare jobs guickly and efficiently for rendering 
on appropriate processors. 


Establish Guidelines 

Given a good understanding of both systems' strengths and 
weaknesses, a set of guidelines will be drawn up for use at 
all sites in determining the most cost-effective approach to 
any given job. 
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What Is The DP Technology 
It is important to recognize that the value of the DP Tech- 


nology lies in the fact that it is a mature, well exercised, 
functional SYSTEM which addresses the problems of producing 
computer graphics for the motion picture industry. While 
aspects of the system are highly optimized, (such as the 
rendering code on the Cray), it is not clear that the 
overall process is being used cost effectively. This orien- 
tation is due in part to an admirable committment to product 
excellence by the DP staff, and in part to the lack of em- 
phasis placed on cost management in the past. 


The principal elements of the system are: 


Supercomputer Rendering 
A Cray-based rendering engine with vectorized code permits 


low to moderate scenes to be rendered quickly, or very high 
complexity scenes to be rendered where they would otherwise 
be impractical. The following are ROUGH GENERALIZATIONS 
based on experience at Omnibus and DP, and do not take into 
account complex rendering situations like shadows or tran- 
sparency. Exact benchmark comparisons that would apply in 
all cases are impossible to make. (See Graph #1) 


FILM FRAME RENDERING (5Mpixels) 


#Palys CRAY /DP3D* Fl/TRANEW VISIONS/CCI 
50 - 100k 18 - 30 300 - 900 300 - 900 
100 - 250k 30 - 90 N.P 900 -3600 
250 - 500k 90 - 180 N.P. N.P. 

500 - 1M 180 - 440 N.P. N.P. 

L - 2M 480 -1200 N.P N.P. 

VIDEO FRAME RENDERING (0.3Mpixels) 

#Polys CRAY/DP3D^ PRISMS/CCI PRISMS/VAX 
50 = 100k AO. - 20 180 - 360 360 - 2400 
100 - 250k 20 = 60 360 -1200 N.P. 
250 - 500k 60 -120 N.P. N.P. 
500 - 1M 120 -270 N.P N.P. 

L S 2M 270 -660 N.P N.P. 


Notes: ASingle-head CPU time. N.P.= not practical 
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Supercomputer Rendering (continued) 


High-Bandwidth Film 1/0 7 

The three DFP OMU’s (Digital Film Printer Optical/Mechanical 
Units) are connected via a custom interface to the Cray’s 
l00Mbyte/sec bus. Film printing and/or scanning can be ac- 
complished in roughly 20 seconds per frame. (It should be 
noted that the Fl film recorder ìs 6-10 times slower.) One 
OMU is set up for printing only, a second for scanning, and 
the third one is being prepared to function in either capa- 
city. 


This means that a sequence can be run with per-frame scan- 
ning for reflection or texture maps or background pictures, 
while the final frame is computed and printed in one step. 
(Thus the name Digital Film Printer). These three devices 
are the fastest and highest quality film printer/scanners in 
existence today. Triple-I is currently leasing them to DP, 
and has expressed interest in selling them outright, along 
with the rights to reproduce additional units. 


High Bandwidth Video Output 
Recently, an Abekas A62 Digital disk system has been inter- 


faced to the Cray 100 Mb/sec bus, and is capable of accept- 
ing digital data directly as encoded NTSC video. So far, 
this interface appears to reguire 5 seconds per frame to 
load. 


Purchase of an Abekas unit and a 1" VIR should be a top 
priority, as DP is currently spending $100-150k per year 
doing motion and low-resolution tests on film. The Abekas 
unit would permit direct video output, and result in signi- 
ficant savings. 


Production Preparation System 
Without a doubt, DP has built up a powerful approach to pro- 


duction management. By breaking the production process into 
distinct and clearly defined steps, staff members are more 
compartmentalized, but are able to concentrate on only their 
function during a production. This approach makes the bid- 
ding, scheduling, and assignment of various job tasks much 
more straight-forward, and could potentially make job cost 
monitoring fairly simple. 


(Note: Appendix one is a DP document describing the produc- 
tion process.) 
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ENCODE 

The software for digitizing (called encoding by DP) runs on 
an Evans € Sutherland PS-300 vector display hosted by the 
VAX. It uses two cursors, and is set up to create 3D data 
from mechanical drawings or photographs using large tablets. 
There are four workstations for encoding, and seven 
Designer/Encoders. 


As in PRISMS, there are many programs for operating on ob- 
ject data. One very powerful capability is the integration 
of BitStream's fonts with utilities to quickly create 3-D 
letters of any style. One of the tablets is set up to per- 
mit pin-registered film rear-projection, which is useful for 
rotoscoping or witness point tracking (used in matching cgi 
and live action.) 


The PS-300 is capable of high-resolution vector displays of 
objects, and thus can handle more complexity than the IRIS 
or V550. 


PREVUE 

The software for motion is called PREVUE and runs on the 
IMI-500 hosted by the VAX. Again, the vector display is ca- 
pable of handling much more complexity in real-time than is 
the IRIS. Despite this capability, the IMI is not capable 
of real-time display of some scenes, and these must be shot 
frame at a time off the screen either onto film or a Lyon- 
Lamb. The same camera system can be used to project film 
images onto the IMI screen, which is useful in matching live 
action footage with computer generated objects or back- 
grounds. 


The motion work is done by the Technical Director. There are 
nine TD's and a Manager. 


FIFTH and TRACK 

FIFTH is the common language developed and used as reguired 
in any phase of the production process. It may be used in 
ENCODE to assist in generating objects, it may be used in 
PREVUE to assist in generating motion or camera paths. TRAC 
is a macro package that can be used with FIFTH. While it is 
a very flexible interactive environment for a programmer, it 
is not a straightforward system for the creative staff. 
Thus, the TD's are trained in the internals of the rendering 
process, and are essentially programmers. 
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DP3D - Lighting € Shading 
The lighting and shading is also done by the TD’s. This 


generally takes place between 10am and midnight in two 
shifts. There are four high-resolution framebuffers, the 
quadrants of which can be shared by the TD's.: Each can run 
DP3D, the main rendering program, and get 512 resolution 
frames up in 20 seconds to 3 minutes (depending on the 
number of TD's lighting and shading). This speed makes the 
process go much faster especially compared with the PRISMS 
times on the VAX or CCI. 


Final Filming a 

Filming periods are from l0pm to l0am weekdays (mostly used 
for low-resolution lighting or motion tests) and all weekend 
for final filming with the Cray dedicated to this task. 


This pattern has developed over time, since final filming 
during the days would lengthen TD turnaround times, and TD 
work would slow down final filming. Again, the Abekas would 
make it possible for tests to be recorded during the TD 
shifts with small impact, and the possiblilty for "back- 
ground filming" during the day is being considered. 


DP3D is structured differently than PRISMS, and is highly 
optimized. It has many advanced features, such as shadows 
(very expensive computationally) reflection mapping, and 
compositing. It is written in Fortran, with many routines 
coded in Cray Assembly Language for speed. We are told it 
is not likely to run on any other machine without consider- 
able work. 


Research and Development 
The Software group consists of seventeen people and a 


manager. Each individual has contributed heavily to various 
aspects of the software, and has developed areas of special- 
ty, ranging from Cray optimization to rendering to film 
colorimetry. Many activities are currently underway which 
should be continued and supported: 


Optimization 

These activities are ongoing speedups on the Cray code, and 
reguire highly-trained Cray Assembly Language specialists. 
There are three consultants that also work in this area. 

One important non-graphics effort is the SARA compiler which 
has been developed to assist in vectorizing code for Crays. 


Copyright (c) Omnibus Research and 
14 Aug 1986 Computer Development 
Version 1 Graphics Inc. Technical Reports 


DP3D/PRISMS Integration Page 6 


Human Figure Animation 
The RTD's (Research Technical Directors) are working on 


several projects to model human movement (PODA), and deal 
with the complexities of rendering human beings (hair, skin, 
etc.) This work needs to be continued, but should perhaps be 
tied toa specific project. It must be stressed that this 
kind of work is important in terms of keeping a leading-edge 
profile in the industry, but it must also be realized that 
this research is fìguring out ways to push complexity levels 
beyond our wildest imaginings. 


Object Scanning 
This work involves a scanning system to permit digitizing 


objects by scanning them on a computerized turntable. It 
could be an important tool, saving countless hours of 
digitizing/encoding. 
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How Can Omnibus Best Use the DP Technology 
The primary question then is how the DP system figures in 


Omnibus’ future operations. There is a tremendous amount of 
capability, but due to the different orientations, the DP3D 
system and the PRISMS system have little in common: 


PRISMS DP3D 
Computer Many possible Cray 
Operating sys Unix COS 
Language C Fortran 
Portability High Low 
Optimization Low High 
Speed Low High 
Complexability Low High 
Workstation IRIS Cray, E&S, IMI 
Animation C-shell,SALI FIFTH 
Aggregate Cost Low High 


For these reasons, integrating the two systens is not a sim- 
ple task. The primary thing the two systems have in common 
is that they generate images from polygonal data of 3D ob- 
jects. Thus, the first task should be to build data conver- 
sion tools which allow objects from one system to be used on 
the other. Due to the different approaches to animation, 
preparation of whole jobs to be run on the Cray will need to 
be done using existing DP workstations, with test rendering 
on the Cray. 


Remote DP3D Site 

One possible approach under consideration would be to con- 
vert an Omnibus site to DP3D. This would require conversion 
of an existing site's VAX to VMS, purchase of at least one E 
& S PS-300, one IMI 555, and a framebuffer. The Encode and 
Prevue code would be run on these systems, and a 56kb data 
circuit would be leased to DP's VAX. This would permit test 
pictures to be run on the Cray from the remote site, with 
low-resolution frames taking 2-5 minutes to render and 
transmit. 


Total capital outlay for this approach using existing Om- 
nibus VAX hardware would approach $500k, with annual fees 
for maintenance and data circuits in the $100k range. It is 
not clear at this time that the Cray at DP can support this 
additional burden without impacting present production and 
DSI committments. 
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Remote DP3D Site (continued) 


Complexity VS Rendering Time 
Before such a decision can be arrived at, the cost perfor- 


mance of the various systems at Omnibus must be considered. 
Graph #1 presents curves of the various Omnibus computer 
systems’ rendering times plotted against complexity. For 


sake of comparison, polygon count is a rough indicator of 
complexity. Many factors such as transparency, shadows, 


depth complexity, and shading can affect this number; howev- 
er, the average case is considered here. It should be noted 
that these numbers do not represent the results of specific 
test cases, but instead represent the average experienced 
curves for each system. It is expected that as more specif- 
ic information is gathered, the model will become more accu- 
rate, and complexity factors (C.F.) for the above features 
can be determined. Nevertheless, for purposes of rough com- 
parison, the chart seems to fit with experience. 


The X axis is time per frame in seconds, and calibration 
marks are presented for frames per hour, or F.P.H. Note 
that the CCI, VAX, IRIS, and Fl systems all are pretty much 
limited to the 100k complexity level, while the Cray has 
been demonstrated to produce images of the 2-million com- 
plexity level in twenty minutes. 


The truncation at the bottom end of the curves represents 
the points at which the systems become camera or disk limit- 
ed, meaning that the CPU can compute the image faster than 
the output device can accept it, so the CPU waits for the 
output device. 


Note that the Cray can do dedicated runs with either one or 
two CPU heads, and that the cost per frame as well as the 
limitation on the output device affect the curves according- 


ly. 


No measurement of preparation CPU load, or balance between 
preparation and final shooting has been made or considered 
in these graphs. 


Copyright (c) Omnibus Research and 
14 Aug 1986 Computer Development 
Version 1 Graphics Inc. Technical Reports 


AM 


aiu i 

LU ERE Oy COROT ae 
HH nme AA] 
AA UREA 


A 


== 
co 
ESA 


[nn] A | STH CLN [a] HA pda 
A A der é ueu A 

j TANIRI” TETEN ann al 

Lis Lio s aeu SS Se E ey O | | — __ bi = E — 


COMPLEXITY (#Polys x C.F.) 


5 
En Wu 
=o e rr 
A 


RU NYD 
op Nr Hu 
TITW OT 1] 


KE 


SELE] Hu 
—O I I || HH HT MM EN UG 
e pe EE 


LTT] 
ES ED EF rH 


gma 405 5o iad Roe ee 
£ 10 iT ao 


iL LL 


FRAMES PER HOUR (F.P.H.) 


OMNIBUS RENDERING ANALYSIS 


David W. Sieg 8/10/86 


GRAPH #1 


UU 
N 


DP3D/PRISMS Integration Page 9 


Complexity VS Rendering Time (continued) 


Graph #2 takes this data a step further and plots the cost 
of the machine versus the level of complexity required. The 
machine cost calculations are summarized below. For exam- 
ple, here are the per-frame costs for these complexities: 


100k 50k 20k 
Cray Film (1) $3.50 $3.50 $3.50 
Cray Video (1) $1.70 $0.85 $0.43 
Cray Film (2) $2.60 $1.80 $1.80 
Cray Video (2) $0.85 $0.85 $0.85 
Fl Film frame $17.00 $6.00 $1.20 
CCI Video frame $1.80 $0.75 $0.25 
VAX Video frame $12.50 $6.25 $1.05 
IRIS Video frame $2.80 $0.60 $0.20 


Cost Basis _ 
In order to develop a uniform measurement technique, the 
costs were calculated in the following manner: 


Labor (operators, etc) monthly cost 
+ Lease (disk subsystems etc) monthly cost 
+ Maintenance Contracts monthly cost 
+ Power monthly cost 
+ Straight-line 5 year depreciation monthly cost 


TOTAL / available hours per month = hourly cost 


Machine Labor Lease Maint Pwr Depr Hr/mo $/hr 


Cray 13k 50k 50k 17k 67k 642 311 
Cray (n) 13k 50k 50k 17k 200k 642 514 
Vax780 3k = 2k ok 6.7k 642 19 
CCI 3k = 2k 5k 4.2k 642 15 
F1 5k = 5k lk 25k 600 60 
IRIS lk E 5k a 1.3k 666 4.2 


Note the Cray(n) rate is based on the $12 million burden the 
Cray would normally provide, as opposed to the $4 million 
paid by Omnibus. Graph #3 shows the curves for this rate. 


While this stripped down cost model does not take into ac- 
count the overheads in some facilities, or the real versus 
actual utilization, it does represent a measure of machine 
cost that is uniform for all systems being compared. 
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Ramifications 


Production Decisions 

From this preliminary data, some fairly clear indications 
are apparent. It would seem that for lower complexity work, 
the PRISMS/CCI/IRIS approach is more cost effective than the 
Cray/DP3D one. 


Further, it appears that the least cost effective system in 
the company’s arsenal is the Fl, followed closely by the 
VAX. 


Finally, it is obvious that as the state of the art is ad- 
vanced, the Cray currently has the headroom to handle 
tremendous complexity, and is most cost effective doing so 
for high end feature work. 


As the market demands more complexity, the present low-end 
approach will become less attractive, and less cost-. 
effective. 


Effect on PRISMS Work In 


Progress 
Given this orientation, the goal of PRISMS should be to con- 


tinue with the lower-complexity orientation, with concentra- 
tion on optimization for the Captain Power type of IRIS- 
oriented "manufacturing line." 


There will continue to be jobs of a level of complexity that 
don't make economic sense to run on the Cray, and for the 
near term, PRISMS can fill that gap. 


Since PRISMS has of necessity needed to interface toa 
number of different systems, it is the easiest place to 
develop conversion programs which will allow object data- 
bases to be exchanged with the DP3D world. 


Another likely project would be to incorporate FIFTH and 
TRACK capabilities into the SALI work that is ongoing, so 
that additional levels of compatibility exist between the 
systems. 


If it becomes necessary to develop a rendering compatibili- 
ty, a DP3D shading module could possibly be developed for 
CRYSTAL, which would allow limited approximation of DP3D's 
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Effect on PRISMS Work In Progress (continued) 
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capabilities. 


The issue of licensing PRISMS overseas need not complicate 
matters except for the need to provide licensees with a 
growth path to the "new workstation” orientation. Until 
this is studied further, it can only be assumed that PRISMS 
licensees will benefit from the same interface bridges Om- 
nibus develops for itself while the ultimate workstation is 
developed. 


Effect on DP3D Work In 

Progress 

Without a doubt, the focus of Research and Development 
should be concentrated on advancing the state of the art at 
the high-end facility. Wherever possible this should be 
done either with project backed funding, or grant assis- 
tance. 


A concentrated effort must be made to carefully study new 
supercomputer designs, with an eye toward faster, cheaper 
systems. 


Further developments must be encouraged to make human move- 
ments and realistic rendering possible. 


Integration of the two Systems 
Except for the somewhat "messy" interface programs mentioned 


above, the two systems are so different that attempts to in- 
tegrate them would only waste both group's efforts over the 
next year. Instead, we should concentrate on continuing ap- 
propriate development given the new understanding of the 
proper roles for each system. 


Integration of the two 

Software Staffs 

The two groups of software people are naturally going to be- 
gin working closely on the "new workstation" project. There 
will doubtless be arguments over what the ideal workstation 
should be/do, not to mention what language it should be pro- 
grammed in, and what operating system it should run. This 
will reguire a firm hand guiding the design group, and Lt 
will require input from nearly every individual in the com- 


pany. 


It would be wise to initiate a program of exchanging pro- 
grammers for a week at a time so that the two qroups gradu- 
ally get a feeling for what goes on at the other facility. 
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Integration of the two Software Staffs (continued) 


It would also be wise to begin standardizing (ìn all areas, 
not just software) the titles and roles of various people in 
the company, so that for example, a Patrick DeWarren could 
become an RID at Paramount, etc. 


Operations 


This is an area where DP's orientation has been guite dif- 
ferent from Omnibus’. The Paramount facility has been un- 
able to afford proper operations personnel, or maintenance 
procedures, and has suffered as a result of it. The DP fa- 
cility on the other hand, has developed a very straightfor- 
ward and workable system for dealing with these issues, and 
this should be propagated throughout the company. 


New Facility Planning 
It is becoming obvious daily the problems inherent in multi- 


ple facilities, especially considering the reguirements for 
occasional usage of expensive eguipment on a daily basis. 


The announced intention to plan and build a new facility in 
the 18-24 month timeframe will reguire immediate attention. 
Many supercomputer manufacturers have lead-times in that 
range. Furthermore, most supercomputer systems have very 
special environmental reguirements that most available fa- 
cilities cannot meet. 
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New Workstation Project 

A team of the top software people from both groups should be 
formed which will study the requirements for the ideal 
workstation. The simplification of the creative interface 
must be addressed such that non-programmers can make effec- 
tive use of the system. 


The workstation: should be developed such that the code is 
highly portable, but can perform at very high levels, in 
terms of operator interface, speed, and complexity. 


Interface to supercomputer rendering capability via high- 
speed communications lines is imperative, as is some limited 
form of local rendering capacity. 


Special arrangements with hardware vendors may be required 

to permit development in advance of actual product availa- 

bility. It should be stressed that the workstation Omnibus 
needs does not exist today. Only by careful design, plan- 

ning, and coordination with hardware vendors can we wind up 
in 18-24 months with the workstation we require. 
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